Serveur d'exploration sur la recherche en informatique en Lorraine

Attention, ce site est en cours de développement !
Attention, site généré par des moyens informatiques à partir de corpus bruts.
Les informations ne sont donc pas validées.

The call-by-need lambda calculus

Identifieur interne : 00BB20 ( Main/Exploration ); précédent : 00BB19; suivant : 00BB21

The call-by-need lambda calculus

Auteurs : Zena M. Ariola [États-Unis] ; Matthias Felleisen [États-Unis]

Source :

RBID : ISTEX:7A5CBBDB900E82349AFB6D1CA0C6693F30BDCF39

Abstract

Plotkin (1975) showed that the lambda calculus is a good model of the evaluation process for call-by-name functional programs. Reducing programs to constants or lambda abstractions according to the leftmost-outermost strategy exactly mirrors execution on an abstract machine like Landin's SECD machine. The machine-based evaluator returns a constant or the token closure if and only if the standard reduction sequence starting at the same program will end in the same constant or in some lambda abstraction. However, the calculus does not capture the sharing of the evaluation of arguments that lazy implementations use to speed up the execution. More precisely, a lazy implementation evaluates procedure arguments only when needed and then only once. All other references to the formal procedure parameter re-use the value of the first argument evaluation. The mismatch between the operational semantics of the lambda calculus and the actual behavior of the prototypical implementation is a major obstacle for compiler writers. Unlike implementors of the leftmost-outermost strategy or of a call-by-value language, implementors of lazy systems cannot easily explain the behavior of their evaluator in terms of source level syntax. Hence, they often cannot explain why a certain syntactic transformation ‘works’ and why another doesn't. In this paper we develop an equational characterization of the most popular lazy implementation technique – traditionally called ‘call-by-need’ – and prove it correct with respect to the original lambda calculus. The theory is a strictly smaller theory than Plotkin's call-by-name lambda calculus. Immediate applications of the theory concern the correctness proofs of a number of implementation strategies, e.g. the call-by-need continuation passing transformation and the realization of sharing via assignments. Some of this material first appeared in a paper presented at the 1995 ACM Conference on the Principles of Programming Languages. The paper was a joint effort with Maraist, Odersky and Wadler, who had independently developed a different equational characterization of call-by-need. We contrast our work with that of Maraist et al. in the body of this paper where appropriate.

Url:


Affiliations:


Links toward previous steps (curation, corpus...)


Le document en format XML

<record>
<TEI wicri:istexFullTextTei="biblStruct">
<teiHeader>
<fileDesc>
<titleStmt>
<title>The call-by-need lambda calculus</title>
<author>
<name sortKey="Ariola, Zena M" sort="Ariola, Zena M" uniqKey="Ariola Z" first="Zena M." last="Ariola">Zena M. Ariola</name>
</author>
<author>
<name sortKey="Felleisen, Matthias" sort="Felleisen, Matthias" uniqKey="Felleisen M" first="Matthias" last="Felleisen">Matthias Felleisen</name>
</author>
</titleStmt>
<publicationStmt>
<idno type="wicri:source">ISTEX</idno>
<idno type="RBID">ISTEX:7A5CBBDB900E82349AFB6D1CA0C6693F30BDCF39</idno>
<date when="1997" year="1997">1997</date>
<idno type="url">https://api.istex.fr/ark:/67375/6GQ-5LLN5CSZ-X/fulltext.pdf</idno>
<idno type="wicri:Area/Istex/Corpus">001C33</idno>
<idno type="wicri:explorRef" wicri:stream="Istex" wicri:step="Corpus" wicri:corpus="ISTEX">001C33</idno>
<idno type="wicri:Area/Istex/Curation">001C12</idno>
<idno type="wicri:Area/Istex/Checkpoint">002652</idno>
<idno type="wicri:explorRef" wicri:stream="Istex" wicri:step="Checkpoint">002652</idno>
<idno type="wicri:doubleKey">0956-7968:1997:Ariola Z:the:call:by</idno>
<idno type="wicri:Area/Main/Merge">00C297</idno>
<idno type="wicri:Area/Main/Curation">00BB20</idno>
<idno type="wicri:Area/Main/Exploration">00BB20</idno>
</publicationStmt>
<sourceDesc>
<biblStruct>
<analytic>
<title level="a">The call-by-need lambda calculus</title>
<author>
<name sortKey="Ariola, Zena M" sort="Ariola, Zena M" uniqKey="Ariola Z" first="Zena M." last="Ariola">Zena M. Ariola</name>
<affiliation wicri:level="2">
<country xml:lang="fr">États-Unis</country>
<wicri:regionArea>Computer and Information Science Department, University of Oregon, Eugene, OR</wicri:regionArea>
<placeName>
<region type="state">Oregon</region>
</placeName>
</affiliation>
</author>
<author>
<name sortKey="Felleisen, Matthias" sort="Felleisen, Matthias" uniqKey="Felleisen M" first="Matthias" last="Felleisen">Matthias Felleisen</name>
<affiliation wicri:level="2">
<country xml:lang="fr">États-Unis</country>
<wicri:regionArea>Department of Computer Science, Rice University, Houston, TX</wicri:regionArea>
<placeName>
<region type="state">Texas</region>
</placeName>
</affiliation>
</author>
</analytic>
<monogr></monogr>
<series>
<title level="j">Journal of Functional Programming</title>
<idno type="ISSN">0956-7968</idno>
<idno type="eISSN">1469-7653</idno>
<imprint>
<publisher>Cambridge University Press</publisher>
<date type="published" when="1997-05">1997-05</date>
<biblScope unit="volume">7</biblScope>
<biblScope unit="issue">3</biblScope>
<biblScope unit="page" from="265">265</biblScope>
<biblScope unit="page" to="301">301</biblScope>
</imprint>
<idno type="ISSN">0956-7968</idno>
</series>
</biblStruct>
</sourceDesc>
<seriesStmt>
<idno type="ISSN">0956-7968</idno>
</seriesStmt>
</fileDesc>
<profileDesc>
<textClass></textClass>
<langUsage>
<language ident="en">en</language>
</langUsage>
</profileDesc>
</teiHeader>
<front>
<div type="abstract">Plotkin (1975) showed that the lambda calculus is a good model of the evaluation process for call-by-name functional programs. Reducing programs to constants or lambda abstractions according to the leftmost-outermost strategy exactly mirrors execution on an abstract machine like Landin's SECD machine. The machine-based evaluator returns a constant or the token closure if and only if the standard reduction sequence starting at the same program will end in the same constant or in some lambda abstraction. However, the calculus does not capture the sharing of the evaluation of arguments that lazy implementations use to speed up the execution. More precisely, a lazy implementation evaluates procedure arguments only when needed and then only once. All other references to the formal procedure parameter re-use the value of the first argument evaluation. The mismatch between the operational semantics of the lambda calculus and the actual behavior of the prototypical implementation is a major obstacle for compiler writers. Unlike implementors of the leftmost-outermost strategy or of a call-by-value language, implementors of lazy systems cannot easily explain the behavior of their evaluator in terms of source level syntax. Hence, they often cannot explain why a certain syntactic transformation ‘works’ and why another doesn't. In this paper we develop an equational characterization of the most popular lazy implementation technique – traditionally called ‘call-by-need’ – and prove it correct with respect to the original lambda calculus. The theory is a strictly smaller theory than Plotkin's call-by-name lambda calculus. Immediate applications of the theory concern the correctness proofs of a number of implementation strategies, e.g. the call-by-need continuation passing transformation and the realization of sharing via assignments. Some of this material first appeared in a paper presented at the 1995 ACM Conference on the Principles of Programming Languages. The paper was a joint effort with Maraist, Odersky and Wadler, who had independently developed a different equational characterization of call-by-need. We contrast our work with that of Maraist et al. in the body of this paper where appropriate.</div>
</front>
</TEI>
<affiliations>
<list>
<country>
<li>États-Unis</li>
</country>
<region>
<li>Oregon</li>
<li>Texas</li>
</region>
</list>
<tree>
<country name="États-Unis">
<region name="Oregon">
<name sortKey="Ariola, Zena M" sort="Ariola, Zena M" uniqKey="Ariola Z" first="Zena M." last="Ariola">Zena M. Ariola</name>
</region>
<name sortKey="Felleisen, Matthias" sort="Felleisen, Matthias" uniqKey="Felleisen M" first="Matthias" last="Felleisen">Matthias Felleisen</name>
</country>
</tree>
</affiliations>
</record>

Pour manipuler ce document sous Unix (Dilib)

EXPLOR_STEP=$WICRI_ROOT/Wicri/Lorraine/explor/InforLorV4/Data/Main/Exploration
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 00BB20 | SxmlIndent | more

Ou

HfdSelect -h $EXPLOR_AREA/Data/Main/Exploration/biblio.hfd -nk 00BB20 | SxmlIndent | more

Pour mettre un lien sur cette page dans le réseau Wicri

{{Explor lien
   |wiki=    Wicri/Lorraine
   |area=    InforLorV4
   |flux=    Main
   |étape=   Exploration
   |type=    RBID
   |clé=     ISTEX:7A5CBBDB900E82349AFB6D1CA0C6693F30BDCF39
   |texte=   The call-by-need lambda calculus
}}

Wicri

This area was generated with Dilib version V0.6.33.
Data generation: Mon Jun 10 21:56:28 2019. Site generation: Fri Feb 25 15:29:27 2022